feat: add native Delta Lake scan contrib module (page/row-group pruning) - #5365

Thanks for reconciling this with #4952. The generic envelope, separate source roots, and explicit runtime opt-in look like useful progress. I reviewed 9b393c15 and left eight concrete correctness and compatibility comments. The main concerns are unsafe scalar-subquery pushdown, mixed-authority file routing, and unbounded deletion-vector row-selection memory.

I checked these against Spark/Delta source and used bounded stock Spark 4.0.3 / Delta 4.0.0 and isolated Rust probes. I have not built this PR's full JNI library or run cloud-backed end-to-end tests. The Delta CI suites are green on Spark 3.5, 4.0, and 4.1. I am leaving the already-acknowledged claim-hook, naming, and packaging choices for the existing design discussion.

Rechecked 7e09e04f with five independent review scopes. One additional P2 is inline; I also followed up in the existing threads on the remaining scalar-pushdown, Azure DV store, and DV-memory issues. Verification used exact-source Spark/Delta physical-plan probes and locked-dependency Rust probes, not a full Comet/JNI or live cloud run.

Thanks for addressing the earlier findings. I think the larger file-selection refactor, shared admission/schema cleanup, packaging changes, and broader deployment coverage can be tracked in follow-up PRs. I'd keep the remaining [P1] Azure safety guard, [P2] S3-authentication and AQE lifecycle fixes, and their focused regressions in this PR.

Could we replace spark.comet.scan.deltaNative.enabled with spark.comet.scan.delta.enabled consistently across both Delta contributions, keeping the default false? Please update the config definitions, tests, documentation, and dev scripts together, and use the spark.comet.scan.delta.* prefix for related settings. The intent is one consistent configuration namespace, not another enable flag.

This rename does not depend on changing the separate-JAR packaging. Broader reader-selection behavior can be discussed separately.

Correctness

Re-reviewed cddd9afb1 against 719cba11. The previous P2 is addressed: the helper now preserves scalar-filter presence independently of binding and serialization, and the caller sets has_data_filters even when no predicate survives. Pushdown-disabled and no-scalar-filter paths retain the original common data. Reference-rejected filters still skip updateResult. I found no remaining P1/P2 in this update.

The two regressions check the affected native scan explicitly, require a scalar-subquery expression and an empty planning-time filter payload, and inspect the executed payload for has_data_filters=true with zero predicates. The overflow fixture uses raw TIMESTAMP_MILLIS data, no Delta file statistics, a persisted epoch bound, and disabled EqualNullSafe serialization. This branch uses safe conversion followed by the covering Spark filter. The presence bit does not itself provide a native pruning predicate. The Spark answer comparison is appropriately gated to 4.0+, while the native result is asserted on every profile. Spark 3.5's reference reader can still overflow in this case, consistent with the existing filtered-scan tradeoff.

Validation here is source review, including the maintained Spark 3.5/4.0 and Delta 3.2/4.0 branches. I did not execute the new regressions or rerun benchmarks. The author's before/after execution is a report, not independently reproduced validation. At 05:42 UTC on September 5, all four workflows at this head were action_required, with no head or merge check results. The synthetic merge has the expected base/head parents and the same tree as the reviewed head. Maintained Spark 3.4/4.1 source branches were unavailable, so this review adds no compatibility qualification for them.

Performance

The result object adds no per-row work or additional expression-resolution pass. Disabled pushdown and scans without scalar filters reuse the empty result. The pre-existing additional updateResult call under fused native parents remains unchanged. This fix does not establish globally once-only subquery resolution. No new scan-throughput or pruning improvement is claimed.

Design

Returning presence alongside serialized predicates preserves the shared planner's None versus Some(empty) distinction at the helper boundary. The caller consumes both from one invocation in its lazy serialization path. This is a focused fix that preserves successful pushdown, binding guards, and the covering filter.

Abstraction & complexity

The small result type expresses the two independent outputs without duplicating filter discovery or evaluation. Of 51 feature patches, 48 are unchanged after normalizing blob headers and hunk positions. Only this helper, its caller, and the test suite differ. The intervening base change is an unrelated explode benchmark, and the calendar, DV, planner and cloud-gating implementations retain their previously reviewed source.

Correctness

Re-reviewed head 2b1047d5c2aeacae387535d29a6c1357965bed8f against base 7190df631afe3795914839203c7afe57ea23903c, comparing the update with previously reviewed source cddd9afb1b9f2179e18214a8d12c6b3947f2f96c. This review followed the Delta call sites affected by the updated core scan gates and the intervening base changes.

One new P2 is attached: Delta uses the updated scheme-only probe without core's separate actual-path gate. With a cold file-scheme cache, a supported local Delta table under a newline-containing directory can now be claimed by native execution and fail when object_store decodes the path, instead of retaining Spark's filesystem reader. Maintained Spark 3.5/4.0 SparkPath and Delta 3.2/4.0 TahoeFileIndex preserve the URI encoding passed into the native serializer. This finding is a source control-flow proof, not an executed query reproduction.

The earlier scalar-filter-presence fix and its regression tests are unchanged. Some(empty) still permits safe conversion while retaining the covering Spark filter; it does not establish native pruning. The unchanged DV, read-schema, calendar-rebase and overflow paths introduce no new semantics in this update. This is not a fresh runtime qualification of every type, null, ANSI or boundary combination. Maintained Spark 3.4/4.1 sources were unavailable, so no compatibility claim is made for those versions.

At the authenticated refresh on 2026-09-05 at 21:14 UTC for discussion and 21:15 UTC for CI, all four current-head workflows (CI, CodeQL, PyArrow UDF Tests and Delta Contrib Build Gate) require action; there are no current-head or merge check runs and no current merge SHA. GitHub reports mergeable=false/dirty even though the raw source head's parent is the assigned base. No merge execution is attributed to this review. No local build, component test, query test or benchmark was run; the focused whitespace check passed. The unchanged author-reported test totals do not validate this head.

Performance

The updated Delta resolver normalizes each data/DV URL before deriving its memo key, matching the shared object-store registration key. This adds URL processing per resolution, not per row, while preserving local memoization and the existing configuration-hash/global-cache boundary. The changed Scala gates reuse the planning configuration and selected files. No material additional hot-path issue was established in this update, and no speedup or disabled-path overhead measurement is claimed. Earlier author-reported benchmarks remain historical evidence.

Design

Conservatively declining opted-in vendor S3 aliases is consistent with the existing Delta gates: their configuration-equivalence checks model Hadoop S3A, not the vendor filesystem's consumers. Passing an empty alias set also keeps selected-file checks conservative. However, splitting scheme recognition from path acceptance requires both checks at the contrib boundary because a handled contrib scan returns before core's built-in gates. Applying the existing actual-path check there, with the same libhdfs exemptions, closes the reported failure without changing the extension contract.

Abstraction & complexity

Reusing NativeConfig.parseSchemeSet and the native URL normalizer avoids parallel parsing/key rules. The DV and read-schema abstractions are unchanged. A shared actual-path gate would also prevent core and Delta fallback behavior from drifting; no additional framework or broader refactoring is needed for the attached issue.

Correctness

Re-reviewed 063c9e0a1eba6eb527edd2315d17e3c430970b52 against base 7f1e00189b1ed86f1cb5acd872d97fce694482b1. The new root-path check addresses the reported newline-directory case, and the selected-directory check also covers the shallow-clone source-directory case. The tests assert Spark fallback and matching answers, with direct parser preconditions in the helper tests.

[P2] Validate complete selected paths for converted Delta tables. One case remains in the existing path-fallback discussion. The selected-path gate drops each filename before probing it. Delta does not always generate those names: CONVERT TO DELTA records existing Parquet paths without renaming the files. For an otherwise supported BIGINT table with no mapping or DVs, an ordinary root such as file:///tmp/table can therefore contain part%0A-000.parquet. Both directory probes accept /tmp/table, while the complete encoded filename reaches native planning and object_store rejects its decoded newline. Spark's filesystem reader remains usable. This case predates the latest fix and is a residual of the same fallback issue, not a new regression from this rebase. Please validate the complete selected paths and add a converted-Parquet regression with the rejected character in the basename.

I verified the conversion and URI-preservation contracts against the maintained Delta 3.2/4.0 and Spark 3.5/4.0 sources, followed the current claim and serialization paths, and checked object_store 0.13.2 against its locked archive checksum. This is a source control-flow proof, not an executed query reproduction. Maintained Spark 3.4/4.1 sources were unavailable. No local build, product test or benchmark was run.

The scalar-filter-presence fix remains intact: Some(empty) permits safe timestamp conversion with the covering Spark filter and does not itself supply native pruning. The calendar and DV implementations retain their prior feature changes. I also checked the DataFusion 55.0.0 reader and schema-builder adaptations against exact locked sources, including the shared structural-narrowing change around the calendar wrapper. This does not requalify all runtime combinations after the dependency update to Parquet 59.3.0.

At the September 8, 01:18 UTC snapshot, all four current-head workflows were action_required, with no head or merge check results. The synthetic merge has the expected base/head parents and the same tree as the reviewed head. Earlier reported test totals and benchmarks are historical evidence.

Performance

The added admission work runs during planning. It constructs parent paths for selected files and deduplicates directories before making uncached native probes, so it adds work proportional to the file list without per-row work. That optimization must still validate filenames admitted through conversion. No measured planning or scan-performance result is claimed.

The revised eager reader uses the same byte-range calls as DataFusion 55's reader. Its metadata hint, eager page-index policy, INT96 stamp and encrypted-file exception remain in place. Calendar wrappers still restrict pruning on wrapped columns, and the established DV reservation tradeoff is unchanged.

Design

Sharing core's actual-path probe at the contrib boundary is appropriate because a handled contribution returns before core's built-in gates. Scheme support and directory validity together do not establish that every selected object can be opened. The admission decision needs to cover the same complete paths that execution consumes, including converted files and external locations.

The DataFusion API adaptations preserve the existing shared planner and reader organization. I found no additional verified design defect in this increment.

Abstraction & complexity

Of 51 feature patches, 44 are unchanged after normalizing blob headers and hunk positions. The remaining changes comprise the fallback helper and tests, its core visibility change, and dependency/base integration. The shared schema adapter still applies calendar handling after remapping and beneath casts.

The new helper is small, but its UUID-filename assumption is stronger than Delta's actual file contract. Correcting that boundary does not require a new extension API or a broader reader refactor. This updates the existing P2; no duplicate inline thread is added.

Correctness

Re-reviewed 60dbe45a61c0f29e4a75306c1969334dbf91fd59 against bb9e74020adc228e486f6f4d0fa68292b30bff31. All 51 feature files are byte-identical to the previously reviewed 063c9e0a, and their feature patches are unchanged apart from hunk coordinates and blob indexes. The seven-file head delta matches the upstream base delta.

[P2] The complete selected-path fallback issue remains. The selected-path gate still removes filenames before validation. CONVERT TO DELTA preserves existing Parquet names, so a rejected character in a basename can pass both directory checks and fail after native claim. Please validate complete selected paths and add a converted-Parquet fallback regression. This updates the existing P2, with no duplicate inline thread.

The current claim, URI serialization and native parsing paths still support this source-level finding. I rechecked the maintained Delta 3.2/4.0 and Spark 3.5/4.0 contracts and reused the exact locked object_store source evidence. The dependency lockfile is unchanged. The scalar-filter presence fix and existing calendar/DV behavior remain intact. No new P1/P2 finding emerged from this follow-up.

At September 8, 10:35 UTC, all four current-head workflows were action_required, with zero jobs and no check results. The synthetic merge has the expected base/head parents and the same tree as this head. No local build, product test or benchmark was run. Spark 3.4/4.1 maintained sources remain unavailable. Historical test totals and timings are not current-head validation.

Performance

The rebase adds no Delta-specific work. Directory deduplication still avoids repeated planning probes for the same parent, but it does not validate preserved filenames. The existing DV memory and calendar-pruning tradeoffs are unchanged, with no new measurements.

Design

The opt-in module, shared native reader and Spark fallback design are unchanged. The remaining fix belongs at admission so selected paths the native reader cannot open decline before execution.

Abstraction & complexity

No new Delta abstraction appears in this rebase. Complete-path validation can remain in the existing eligibility helper. That boundary check does not require a new extension API or a separate reader ownership layer.

Correctness

Re-reviewed 288cf0731c4677df48e7ce82b3045d1b69867163 against base 8e6846850c525506dd2b9194f2014e8acd2ab60a, which is also the actual merge base. All 51 authored patches match the last published review after normalizing diff metadata, and all 51 authored file blobs equal the previous unpublished head. The intervening concat_ws array support and Spark 4.1 Variant test-fixture update are inherited verbatim from the base. The new expression routing leaves Delta admission, filter-presence serialization, and native file preparation unchanged.

[P2] Complete selected-path validation is still required. The gate still strips basenames before validation. Maintained Delta 3.2/4.0 conversion preserves existing Parquet names, and maintained Spark 3.5/4.0 preserves their URI encoding. An unsupported basename can pass directory validation and fail during native file preparation. Please validate complete selected paths and add a converted-Parquet fallback regression. The existing P2 remains unresolved. No new P1/P2 emerged.

At September 8, 16:56 UTC, all four current-head workflows were action_required, with no head or merge check results. The synthetic merge has the expected base/head parents and equals the head tree. This is a source review with verified reuse of unchanged source and discussion evidence. No build, product test, or benchmark ran locally. Maintained Spark 3.4/4.1 sources remain unavailable. The inherited test changes do not establish runtime qualification.

Performance

Delta file listing, directory deduplication, and deletion-vector reservations are unchanged. The inherited concat_ws adapter handles runtime scalars once for broadcasting. Its benchmark source provides no measured Delta speedup here.

Design

The existing admission helper can reject complete paths before native execution. The inherited expression routing retains the previous string kernel and does not alter the Delta extension boundary.

Abstraction & complexity

No Delta-specific abstraction was added. The remaining correction fits the eligibility helper without changing reader ownership or the extension API.

Correctness

Re-reviewed a51cc0c2b680074bd7966c6e3aa9d20c517ab624 against fefee03d94045ecd0ac5d3a1edb98a555f5ff21d, which is also the merge base. The 51 existing authored file patches retain the same added and removed lines. The only additional authored change supplies false, "CORRECTED", "CORRECTED" to two Parquet test constructors introduced by the rebase. These correctly keep the ordinary-reader fixtures outside Delta's per-file calendar-rebase path.

The inherited runtime-filter integration preserves the file groups, deletion-vector extensions and expression adapter when replacing a Parquet source. It remaps predicates through the scan projection and combines them with the existing predicate. Both native Delta scanning and join dynamic filtering remain opt-in. Reader attachment is limited to eligible inner integer-key joins and does not cross a fetch limit or a residual expression beyond direct-column null checks. Source inspection found no new issue with the existing column-mapping, deletion-vector or fallback boundaries.

[P2] The complete selected-path check remains outstanding. DeltaScanSupport still validates parent directories after removing the filenames. Maintained Delta 3.2/4.0 conversion preserves existing Parquet basenames, and maintained Spark 3.5/4.0 preserves their URI encoding. A basename rejected by the locked native path parser can therefore pass admission and fail during native file preparation. Please validate the complete selected paths and add the converted-Parquet fallback regression described in the existing thread. No duplicate inline or new P1/P2 is added.

Validation

The synthetic merge ef9453744c74e59ec8dab2dbe50f99cdf0dc9a3a has the exact base/head parents and equals the head tree. At September 9, 04:15 UTC, CI, the Delta build gate, CodeQL and PyArrow workflows were all action_required, with no jobs. The sole successful check was the labeling workflow, which checked out the base. No current-head build or test execution is established. This follow-up uses verified source equivalence and focused source inspection. No local build, query test or benchmark ran. Maintained Spark 3.4/4.1 sources remain unavailable.

Performance

The Delta listing, schema adaptation, deletion-vector preparation and calendar-rebase implementation are unchanged. The inherited opt-in runtime filter clones scan configuration while preserving the adapter and attached DV extensions. No new default-path scan cost was identified in this update. The unchanged benchmark numbers remain author reports and do not establish a measured benefit at this head.

Design

The rebase keeps runtime filtering inside the existing Parquet pushdown contract and preserves the residual filter. The remaining path correction belongs in admission, where it can still choose Spark fallback before native file preparation fails.

Abstraction & complexity

The update adds no Delta-specific abstraction. The two explicit test-constructor settings match the extended reader API without changing the Delta configuration or ownership interfaces.

All five of the points I raised on 2 September are resolved. The case-folding stack is gone and the Delta scan now inherits main's name_fold ASCII fast path from #5602, the per-scan case tables and the QueryContextInternerSuite pin went with it, JvmLowercaseParitySuite is gone, the three small core fixes shipped as #5653, the field-id semantics moved to #5654, the reserved "delta_scan" line in operator.proto is dropped, and the doc comments in DeltaScanSupport.scala no longer reference symbols that are not in the tree. The core surface that remains is datetime_rebase.rs and its wiring, which the description calls out and tracks under #5010 and #5662. I traced the off switch and it holds: rebase_from_file_metadata is false at every call site except delta_spark_scan.rs, so a plain NativeScan is unchanged. Thanks for doing the split.

The restructure has left one thing stale. dev/verify-contrib-delta-gate.sh exists to prove that "the DEFAULT cargo / mvn / dylib build carries ZERO Delta surface" and asserts zero Delta symbols in the default libcomet. With delta now in default = ["hdfs-opendal", "delta"], that statement is no longer accurate, since the default dylib carries delta_dv.rs, delta_spark_scan.rs, roaring and crc32fast. The gate still reports OK only because delta_syms greps for comet_contrib_delta|delta_kernel|deltadvfilter|deltasynthetic and none of the new symbols match those names. Could the script and the header comment in .github/workflows/delta_build_gate.yml be reworded to the invariant that actually holds now, and could the gate pin the new one, for example that --no-default-features pulls in neither roaring nor crc32fast and that the default-on surface stays near the 82 KB you measured? Nothing in CI has run on this head, so that gate has not been exercised either way.

The other change outside the module is in pom.xml. The new <ignoreClass>org.apache.comet.*</ignoreClass> for comet-common-spark... sits in the root <build> enforcer configuration rather than inside the delta profile, so it turns off duplicate-class detection for every Comet class in every build, to work around a reactor collision that only happens under -Pdelta. Would excluding the transitive comet-common from contrib/delta-spark's comet-spark dependency work instead? The shaded jar already bundles those classes, so the module should still compile and the repo-wide check would stay intact.

On the default cargo feature, @viirya asked for a maintainer call rather than another round, so here is mine. I am fine keeping delta in the default set at 82 KB, given the code is unreachable without both the contrib jar and spark.comet.scan.delta.enabled, and I would rather people can try this against a stock binary than have to build native themselves. Please treat that as settling #5411's opposite ask and keep the Cargo.toml comment pointing at it.

I did not re-review the contrib itself, since @sunchao has been through it many times, but I did check the two things in the read path I care about most and both hold. ParquetAccessPlan::scan_selection intersects with an existing Selection rather than overwriting it, so a DV selection survives page-index pruning, and SparkDatetimeRebaseExpr is opaque to PruningPredicate, so a rebased column loses pruning instead of pruning wrongly. Throwing on RowIndexFilterType.IF_NOT_CONTAINED in extractDvDescriptor is the right call too. @sunchao's selected-path finding around DeltaScanSupport.scala:318 still looks open at this head, so I am leaving this as a comment for now. The reason for my earlier changes-requested is gone and I will switch to approve once that and the build-gate question are settled.

Correctness

Rechecked b1de375d against 424c31aa after the latest review. All 52 authored file patches retain the added and removed lines from the last published review at a51cc0c2. The 22-file increment since then is inherited from base updates. The latest six-file base change enables FIRST/LAST partial merging above any scan. Its overlap in operators.scala leaves the authored Delta scan-metric changes intact. I found no new Delta-specific issue in that interaction.

[P2] The complete selected-path check remains outstanding. DeltaScanSupport still removes basenames before validating selected paths. Maintained Delta 3.2/4.0 conversion preserves existing Parquet basenames, and maintained Spark 3.5/4.0 preserves their URI encoding. Native file preparation still parses each complete path. The root/directory fix therefore does not cover the converted-file case in the existing discussion. Please validate complete selected paths while fallback remains possible and add the converted-Parquet regression. I am not adding a duplicate inline.

The Delta/DV/rebase sources and locked dependencies are unchanged from the inspected revision. The retained exact-release source evidence still supports DV/page-selection intersection and conservative fallback for unsupported rebase predicates. Delta enables per-file rebasing, ordinary NativeScan disables it, and encoded inverse DV filter types remain rejected.

At 16:10 UTC on September 9, CI, the Delta build gate, CodeQL and PyArrow remain action_required, each with zero jobs. The only successful job performed labeling and its log confirms checkout of base 424c31aa. Synthetic merge cdcb83e2 has the assigned base/head parents and equals the head tree, but no build/test execution of that tree is established. This review used source comparison and reused checksum-verified dependency/enforcer evidence after checking source and lock equivalence. No native/JVM test, build gate or benchmark was run. Maintained Spark 3.4/4.1 sources remain unavailable.

Performance

The maintainer's decision settles keeping delta in the default native feature set. The contrib jar and scan setting still gate use, and this rebase does not change the authored scan, DV or calendar-rebase implementation. The approximately 82 KB size increase and scan timings remain author-reported measurements. The current gate compares defaults against defaults plus contrib-delta, so that comparison does not independently measure the cost of the separate delta feature.

Design

The build-gate request remains applicable. Its workflow still promises zero Delta surface, while delta_syms matches comet_contrib_delta|delta_kernel|deltadvfilter|deltasynthetic, which does not match delta_dv or delta_spark_scan. Also, the dependency tree labeled default is obtained with --no-default-features, whereas the later default-library build enables defaults. Please align the wording and checks with the accepted distinction between the default JVM-planned Delta support and the optional kernel contrib.

A blanket assertion that --no-default-features contains no crc32fast would be incorrect: core depends unconditionally on the shuffle crate, which has its own unconditional crc32fast dependency. Check Delta-specific feature activation and opt-out instead of global package-name absence. Any size comparison intended to isolate delta should otherwise keep the feature set identical.

Abstraction & complexity

The duplicate-class concern also remains, with a narrower scope than the review's wording suggests. The ignore is specific to the comet-common artifact, as confirmed in the configured enforcer 1.7.0 implementation and its per-dependency rule contract. It does not disable checks for every Comet class in arbitrary artifacts. However, placing it in the root build makes that common-artifact exception apply outside the Delta profile. Please contain it in the contrib module/profile or remove the duplicate dependency path there. Excluding transitive comet-common is plausible for the shaded-jar path, since shading bundles it at package. Please validate clean reactor test and package lifecycles before relying on that alternative. I have not built the proposed exclusion.

Correctness

Rechecked 5903eb03229738f21514f32bd77fc32134c7e17d against 424c31aa79d13fddf743ffa29bae3c6f146e6c5e after review 5156929953. The base is unchanged. I read the six-file increment and reused the prior review for the 46 unchanged authored files. I found no new or remaining verified P1/P2 findings and approve this revision.

The selected-path P2 is addressed. The gate now probes complete selected data-file and external-DV URIs before conversion, with deduplication and the existing libhdfs exemptions. This matches maintained Delta 3.2/4.0 preserving converted Parquet basenames and maintained Spark 3.5/4.0 preserving URI encoding. The new converted-Parquet regression checks the absence of a native Delta scan, the matching Spark answer and a fallback reason containing the rejected basename. The helper test also checks that the parent passes while the complete filename fails, so an unavailable native parser cannot make that test pass vacuously.

At 2026-09-09T19:35:30Z, CI, Delta Build Gate, CodeQL and PyArrow still require maintainer action and have zero jobs. Only labeling passed, on base 424c31aa. Synthetic merge 0bfe12ad has the assigned parents and the same tree as HEAD, but no product test ran on it. The author's reported query and reactor runs are separate from this evidence. I ran only the Maven inheritance component check described below. No native/JNI query or benchmark was run. Maintained Spark 3.4/4.1 source coverage remains unavailable.

Performance

Full-path validation adds one uncached native parse per distinct selected URI, replacing the directory-only probe. The source confirms that the probe performs URL/path parsing without storage I/O, and the existing planning helper is reused rather than listing files again. The reported 0.75 microseconds per file over 200,000 paths is an author measurement, not an independently measured end-to-end planning cost. The benchmark file changes are comments only, and the native scan/DV/rebase implementations are unchanged.

Design

The earlier build-gate request remains open. The script and workflow are unchanged, so a reported passing run does not settle it: the workflow still promises zero default Delta surface, the symbol pattern still omits the new delta_dv/delta_spark_scan surface, and the tree labeled default still disables default features. Please align the wording and checks with the accepted default delta versus optional kernel contrib-delta split. A size comparison should isolate the intended feature, and global crc32fast absence is not a valid opt-out test because shuffle also depends on it. That existing maintainer request remains open. This approval does not mark it resolved, and I am not adding a duplicate inline.

Abstraction & complexity

The duplicate-class scope request is addressed. The exception is removed from the root and appended to the Delta module's existing enforcer execution. Using the repository's pinned Maven 3.9.6 inheritance implementation against the exact POMs, I verified one inherited enforce execution, preservation of the parent's four dependency exceptions and other rules, and the additional common-artifact exception only in Delta. Root, Spark and common remain unchanged by that child configuration. This was a model-inheritance component check, not full effective-model resolution, enforcer execution or clean reactor test/package validation. The module-local exception avoids imposing this workaround on unrelated builds.

The pom item is resolved, and the way you resolved it is better than the alternative I suggested.

The root <build> enforcer no longer carries org.apache.comet.*; it is back to UnusedStubClass and TypeQualifier only, and the exception now lives in contrib/delta-spark/pom.xml under the same execution id with combine.children="append", so it extends the inherited rule for that module alone. Thanks for actually trying the dependency-exclusion route and reporting why it fails: a reactor test run resolving comet-spark from unshaded target/classes and then hitting NoClassDefFoundError: org/apache/comet/CometRuntimeException is a good reason, and it is the sort of thing that would otherwise be re-proposed every six months.

The build gate is still stale, though, and I owe you a correction on part of what I asked for.

What I got wrong

I suggested pinning that --no-default-features pulls in neither roaring nor crc32fast. That invariant does not exist and never did. Both crates are already in the tree transitively without the delta feature:

crc32fast v1.5.1
├── apache-avro v0.21.0 -> iceberg v0.10.1 -> datafusion-comet
└── datafusion-comet-shuffle -> datafusion-comet
roaring v0.11.5
└── iceberg v0.10.1 -> datafusion-comet

So delta = ["dep:roaring", "dep:crc32fast"] adds no new crate to the default build; it only promotes two existing transitive deps to direct ones. That strengthens your case for keeping delta in the default set, and it should go in the Cargo.toml comment next to the #5411 pointer, because "it pulls in two extra crates" is the objection a reader will otherwise assume.

What is still wrong

The gate conflates the two features. dev/verify-contrib-delta-gate.sh's header says it verifies that the build "keeps Delta surface out of default builds" and that layer 1 checks "default cargo build doesn't compile comet-contrib-delta". Neither statement matches the tree:

• default = ["hdfs-opendal", "delta"], and delta gates real code, delta_dv.rs plus eight #[cfg(feature = "delta")] sites in planner.rs. So the default dylib does carry Delta surface. The header claims otherwise.
• Layer 1 runs cargo tree -p datafusion-comet --no-default-features and calls that the default build. It is not: the default tree has 30 opendal lines against 25 without default features, so the command under test is a configuration nobody ships.

The check's substance is fine and I verified it holds where it matters. comet-contrib-delta and delta_kernel are absent from the actual default tree, not just from the --no-default-features one:

default tree contains contrib-delta/delta_kernel: 0
--no-default-features tree contains them: 0

So the fix is small: point layer 1 at cargo tree -p datafusion-comet with no flag, and reword the header and the .github/workflows/delta_build_gate.yml comment to the invariant that actually holds, which is that the heavy kernel-backed contrib-delta crate stays out of every shipped build while the small default-on delta feature is deliberately in. Keeping --no-default-features as an additional case is fine, it just is not the one the prose describes.

The delta_syms grep is the other half. It matches comet_contrib_delta|delta_kernel|deltadvfilter|deltasynthetic, none of which the default-on delta code exports, so the symbol layer reports OK for the same reason the tree layer does, not because the default build is Delta-free. Pinning the default-on surface near the 82 KB you measured would make that layer say something the grep cannot drift away from.

On the selected-path finding, probing every distinct data-file and deletion-vector URI rather than their parents is the right shape, and 0.75 microseconds per file as a pure URL parse with no I/O is comfortably under the scan's own per-file cost. The CONVERT TO DELTA test with a newline in a retained basename is a good regression, and better than a synthetic one because it is how the shape actually arises.

Everything else from my last pass still holds. ParquetAccessPlan::scan_selection intersecting rather than overwriting, SparkDatetimeRebaseExpr being opaque to PruningPredicate, and throwing on RowIndexFilterType.IF_NOT_CONTAINED are all still correct at this head, and my maintainer call on keeping delta default-on stands, now with a better justification than the one I gave.

Happy to approve once the gate says what it checks.

The pom item is resolved, and the way you resolved it is better than the alternative I suggested.

The root <build> enforcer no longer carries org.apache.comet.*; it is back to UnusedStubClass and TypeQualifier only, and the exception now lives in contrib/delta-spark/pom.xml under the same execution id with combine.children="append", so it extends the inherited rule for that module alone. Thanks for actually trying the dependency-exclusion route and reporting why it fails: a reactor test run resolving comet-spark from unshaded target/classes and then hitting NoClassDefFoundError: org/apache/comet/CometRuntimeException is a good reason, and it is the sort of thing that would otherwise be re-proposed every six months.

The build gate is still stale, though, and I owe you a correction on part of what I asked for.

What I got wrong

I suggested pinning that --no-default-features pulls in neither roaring nor crc32fast. That invariant does not exist and never did. Both crates are already in the tree transitively without the delta feature:

crc32fast v1.5.1
├── apache-avro v0.21.0 -> iceberg v0.10.1 -> datafusion-comet
└── datafusion-comet-shuffle -> datafusion-comet
roaring v0.11.5
└── iceberg v0.10.1 -> datafusion-comet

So delta = ["dep:roaring", "dep:crc32fast"] adds no new crate to the default build; it only promotes two existing transitive deps to direct ones. That strengthens your case for keeping delta in the default set, and it should go in the Cargo.toml comment next to the #5411 pointer, because "it pulls in two extra crates" is the objection a reader will otherwise assume.

What is still wrong

The gate conflates the two features. dev/verify-contrib-delta-gate.sh's header says it verifies that the build "keeps Delta surface out of default builds" and that layer 1 checks "default cargo build doesn't compile comet-contrib-delta". Neither statement matches the tree:

• default = ["hdfs-opendal", "delta"], and delta gates real code, delta_dv.rs plus eight #[cfg(feature = "delta")] sites in planner.rs. So the default dylib does carry Delta surface. The header claims otherwise.
• Layer 1 runs cargo tree -p datafusion-comet --no-default-features and calls that the default build. It is not: the default tree has 30 opendal lines against 25 without default features, so the command under test is a configuration nobody ships.

The check's substance is fine and I verified it holds where it matters. comet-contrib-delta and delta_kernel are absent from the actual default tree, not just from the --no-default-features one:

default tree contains contrib-delta/delta_kernel: 0
--no-default-features tree contains them: 0

So the fix is small: point layer 1 at cargo tree -p datafusion-comet with no flag, and reword the header and the .github/workflows/delta_build_gate.yml comment to the invariant that actually holds, which is that the heavy kernel-backed contrib-delta crate stays out of every shipped build while the small default-on delta feature is deliberately in. Keeping --no-default-features as an additional case is fine, it just is not the one the prose describes.

The delta_syms grep is the other half. It matches comet_contrib_delta|delta_kernel|deltadvfilter|deltasynthetic, none of which the default-on delta code exports, so the symbol layer reports OK for the same reason the tree layer does, not because the default build is Delta-free. Pinning the default-on surface near the 82 KB you measured would make that layer say something the grep cannot drift away from.

On the selected-path finding, probing every distinct data-file and deletion-vector URI rather than their parents is the right shape, and 0.75 microseconds per file as a pure URL parse with no I/O is comfortably under the scan's own per-file cost. The CONVERT TO DELTA test with a newline in a retained basename is a good regression, and better than a synthetic one because it is how the shape actually arises.

Everything else from my last pass still holds. ParquetAccessPlan::scan_selection intersecting rather than overwriting, SparkDatetimeRebaseExpr being opaque to PruningPredicate, and throwing on RowIndexFilterType.IF_NOT_CONTAINED are all still correct at this head, and my maintainer call on keeping delta default-on stands, now with a better justification than the one I gave.

Happy to approve once the gate says what it checks.